FNP - Advanced - Delete Operations & Visibility Control
Summary (Explain Like I’m 5)
Imagine a Google Doc where you delete text. The server stores:- The deleted text (encrypted)
- A flag saying “deleted”
- A proof saying “I’m authorized to delete this”
- Multi-user: Other users might not have received the edit yet
- Offline editing: User offline might insert text at position being deleted
- Replication: Different regions might see delete at different times
- Audit trail: History of what was deleted and by whom
Technical Deep Dive
Delete Operation Protocol:Mermaid Diagrams
Key Terms
- Visibility Flag → Boolean marking character deleted (still stored for CRDT)
- Merkle Proof → Cryptographic proof of membership in tree (constant size)
- Idempotent Operation → Delete same character twice = single delete (no error)
- Causal Consistency → Operation ordering respects happens-before relation
- Undelete → Future feature; restore character with audit trail
- Audit Trail → History of all modifications (who, when, what action)
- Orphaned Character → Visible character whose parent is deleted
- Deletion Timestamp → When character marked invisible; separate from creation
Q/A
Q: Why not permanently delete characters from server storage? A: CRDT semantics require all operations to be commutative. If offline user inserts text at deleted position, they don’t know position was deleted. Keeping deleted chars (marked invisible) ensures consistent merge. Also: audit trail, recovery, regulatory compliance. Q: How does deletion work if multiple users are editing same text? A: LSEQ gives each character unique ID. Delete operation targets specific ID (not position). Even if other characters inserted/deleted around it, target character ID remains constant. Delete finds and hides that specific ID. Q: Can I recover deleted text? A: Server stores encrypted deleted text (marked invisible). Deleted text remains encrypted. Only user who encrypted it (has Kyber_sk) can decrypt historical version. Recovery is manual (export encrypted document history). Permanent deletion requires cryptographic destruction. Q: What prevents user from forging a delete proof? A: Halo2 circuit verifies: (1) Merkle path is valid in current document, (2) Dilithium signature proves authorization. Forging proof requires breaking lattice hardness (LWE) or discrete log (DSA). Cryptographically infeasible. Q: What if server crash loses visibility flags? A: PostgreSQL persistence layer stores operation log. On restart, replay operations in Lamport clock order. All deletes replayed → visibility flags restored from log. No data loss. Q: How many concurrent deletions can system handle? A: As many as proofs can be verified (~1000s ops/sec). Each DELETE generates independent proof. No global lock needed. Parallelizable across server replicas.Example / Analogy
Shared Notebook Analogy: Imagine a physical notebook passed between 3 friends: Without proper deletion (naive approach):- Friend 1 writes “Hello”
- Friend 2 erases word with permanent marker
- Friend 3 (offline, working on copy) doesn’t know about erasure
- Friend 3 inserts “Goodbye” at erased position
- Now both friends have different notebooks ✗
- Friend 1 writes “Hello” at position [A, B, C]
- Friend 2 says “I want to hide [A, B, C]” (with proof)
- Friend 2 crosses out [A, B, C] but leaves pencil marks (visible = false)
- Friend 3 (offline) inserts “Goodbye” between [A, B, C] and [D, E]
- Both friends compare: [A, B, C (crossed), Goodbye, D, E]
- When Friend 3 learns [A, B, C] is crossed: both show [Goodbye, D, E] ✓
Cross-References: FNP Protocol Flow, LSEQ CRDT, Halo2 Circuits, CRDT Semantics Category: Protocol | CRDT | Data Management | Advanced Difficulty: Advanced ⭐⭐⭐⭐ Updated: 2025-11-28